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1.   INTRODUCTION 


An  Inferential  Computer  Consultant  is  being  designed 
and  implemented  at  the  University  of  Illinois  by  a  research 
cjroup  headed  by  Professor  B.S.  Hichalski.  The  computer 
consultant  is  intended  to  extend  the  capabilities  of  current 
information  systems  by  including  deductive  capabilities  and 
introducing  inductive  capabilities.  Induction  is  performed 
using  Variable- Valued  Logic  techniques  [ 1 ]  on  sets  of  facts 
called  event  sets.  These  event  sets  are  most  naturally 
stored  using  relational  tables  as  proposed  by  Codd[2j. 

In  the  Variable-Valued  Logic  system  VL1[3]  an  event  is 
an  ordered  list  of  values  of  a  corresponding  list  of 
descriptors.  An  event  set  is  simply  a  set  of  events 
corresponding  to  one  list  of  descriptors.  It  therefore 
seems  natural  to  represent  an  event  set  by  a  relational 
table,  where  a  row  (or  tuple)  corresponds  to  an  event  and  a 
column  (or  domain)  corresponds  to  a  descriptor.  In  order  to 
allow  for  the  creation  and  manipulation  of  these  relational 
tables,  a  data  base  sublanguage  (intended  to  be  a  subset  of 
the  entire  language  for  communication  with  the  computer 
consultant)  has  been  developed.  The  description  of  this 
sublanguage  is  the  object  of  this  thesis. 


The  design  of  the  sublanguage  was  begun  by  Professor 
Michalski  for  a  course  he  taught  on  information  systems  at 
the  University  of  Illinois  in  the  spring  of  1976  after  he 
became  disenchanted  with  some  of  the  awkward  constructs  of 
Codd's  relational  data  sublanguage  ALPHA[4].  The  basic 
design  was  taken  from  a  combination  of  ALPHA  and  the 
language  VL1.  This  basic  design  was  then  organized  and 
extended  by  the  author.  A  computer  program  to  implement  the 
sublanguage  was  initiated  by  Trevor  Morgan,  Greg  Lyons,  and 
warren  Emery  as  a  semester  project  for  the  information 
systems  course  and  is  being  continued  by  the  author. 


2.    DESCRIPTION  OP  THE  SUBLANGUAGE 


The  VL  data  sublanguage  has  instructions  for  creating, 
retrieving,  and  modifying  relational  tables  plus  some  which 
use  existing  tables  for  the  purposes  of  induction  or 
deduction.  The  instructions  which  make  up  each  of  these 
categories  are  explained  in  detail  below* 

Relational  tables  are  created  and  expanded  by  two 
instructions,  the  DEFINE  and  the  ADD.  The  DEFINE 
instruction  is  used  to  define  the  characteristics  of 
relational  tables.  The  keyword  RT  following  DEFINE  signals 
that  the  user  is  defining  relational  tables,  while  the 
keyword  EVENT  in  that  position  indicates  that  the  user  is 
defining  events,  which  may  be  thought  of  as  relational 
tables  with  only  one  row;  if  no  keyword  is  given  (following 
DEFINE) ,  then  RT  is  assumed  by  default. 

In  defining  a  new  table,  the  user  specifies  the  table 
name,  the  names  of  the  descriptors  (which  are  the  column 
headings  for  the  table) ,  and  the  names  of  those  descriptors 
(if  any)  which  make  up  the  key  of  the  table.  The  key  is  a 
subset  of  the  descriptors  which  can  be  used  to  identify  a 
given  event;  the  key  must  be  unigue  from  one  event  to 
another.  Usually  there  is  only  one  descriptor  in  the  key, 
although  any  number  of  the  descriptors  may  make  up  the  key. 
These   descriptors   should   be   the   first   given    in    the 


descriptor  list  (in  this  definition)  and  should  occur  in  the 
same  order  in  the  descriptor  list  as  they  do  in  the  key 
list.  For  example  in  defining  a  relational  table  T  with 
descriptors  A,  B,  C,  D,  and  E,  if  the  key  is  C,D,  then  the 
table  would  be  defined  using  the  instruction: 

DEPINE  T(C,D,A,B,E)  K£Y:=C,D  END 

This  table,  as  defined  above,  will  be  used  in  examples 
throughout  this  chapter.  The  table  name  (T,  in  this  case) 
should  not  be  used  anywhere  else  as  a  table  name,  an  event 
name,  a  descriptor  name,  or  a  value  name,  and  must  be 
distinct  from  the  keywords  of  the  sublanguage.  The  same 
restrictions  hold  for  the  descriptor  names  except  that  the 
same  descriptor  may  appear  in  more  than  one  table.  Hore 
than  one  relational  table  may  be  defined  in  the  same  DEFINE 
instruction  (which  is  delimited  by  the  keywords  DEFINE  and 
END)  simply  by  listing  the  definitions  one  after  another 
(the  optional  keyword  HT  occurs  only  once,  after  the  word 
DEFINE)  . 

In  defining  a  new  event,  the  name  of  the  event  is  given 
followed  by  the  descriptor  names  and  their  corresponding 
values.  A  value  may  be  given  as  an  integer,  a  real  number, 
an  arithmetic  expression  of  integers  and  reals,  a  character 
string  (enclosed  in  single  guotes) ,  or  a  value  name,  which 
is   an   alphanumeric  string  which  begins  with  a  letter.   The 


restrictions  on  the  name  of  the  event  are  the  same  as  those 
for  that  of  a  new  relational  table.  The  purpose  of  defining 
an  event  is  so  that  it  may  later  be  added  to  some  relational 
table;  however,  the  relational  table  need  not  exist  prior 
to  defining  the  event.  Similarly,  the  descriptors  and/or 
their  corresponding  values  need  not  exist  at  this 
time--using  new  descriptor  (value)  names  in  a  DEFINE  EVENT 
instruction  establishes  them  as  descriptors  (values) •  Bore 
than  one  event  may  be  defined  in  one  DEFINE  instruction  by 
listing  definitions  one  after  another  (the  keyword  EVENT 
occurs  only  once,  after  the  word  DEFINE).  A  typical 
instruction  might  be: 

DEFINE  EVENT 

E1:=   (A:=10,B:=2.3*5.7,D:=TABLE,C:=«GOOD  DAY') 
E2:=   (B:=73. 1,SIZE:=LAHGB,»EIGHT:=185) 

END 

The  ADD  instruction,  which  is  used  to  add  events  to 
relational  tables,  has  three  forms.  The  first,  which  would 
usually  be  used  when  originally  setting  up  a  relational 
table,  offers  the  capability  of  adding  many  events  to  one 
table  in  the  same  instruction.  After  specifying  the  name  of 
the  relational  table  to  which  the  events  are  to  be  added, 
the  user  is  placed  in  insert  mode,  which  the  user  ultimately 
terminates  by  typing  the  word  END.   Prior  to  typing  END,  the 


user  enters  the  values  for  each  of  the  descriptors  in  each 
event  to  be  added;  the  values  within  each  event  are  entered 
in  the  same  order  that  the  corresponding  descriptors  were 
entered  in  the  DEFINE  instruction  for  that  relational  table 
(thus  the  descriptor  names  need  not— and  must  not— be 
specified) •   A  typical  instruction  might  be: 

ADD  TO  T 

(NOI,CHAI 8,6,45.2,42) 

( BAUD, DESK, 7, 36. 0,29* 37) 

(THING, LA HP, 23, 29. 1,16) 

END 

These  three  events  would  be  added  to  the  end  of  T.  The 
second  event  demonstrates  the  use  of  an  arithmetic 
expression  ("29*37")  as  the  value  of  the  descriptor  B. 

The  second  form  of  the  ADD  instruction  is  similar  to 
the  first  except  that  only  one  event  is  listed  and  it  is 
entered  before  the  name  of  the  table  to  which  is  is  to  be 
added.  Also,  since  only  one  event  is  given,  the  keyword  END 
is  not  needed.  This  form  is  intended  to  be  used  to  easily 
add  a  single  event  to  a  table.  An  example  of  this  form 
would  be: 

ADD  (LEFT, SOFA, 21, 14.2,0)  TO  T 


The  third  form  of  the  ADD  instruction  is  identical  to 
that  of  the  second  except  that  instead  of  giving  the  values 
of  an  event f  the  name  of  a  previously  defined  event  (defined 
using  a  define  event  instruction)  is  given.  The  order  of 
the  descriptors  (and  their  corresponding  values)  which  was 
used  in  the  DEPINE  EVENT  instruction  need  not  be  the  same  as 
that  which  was  used  in  the  DEPINE  RT  instruction.  Hot  all 
descriptors  in  the  relational  table  need  appear  in  the  event 
to  be  added  (the  corresponding  values  are  left  undefined)  ; 
however,  the  event  must  not  have  any  descriptors  which  are 
not  in  the  relational  table.  Thus,  to  add  the  event  E1  (as 
defined  above)  the  user  would  enter  the  instruction: 

ADD  E1  TO  T 
NOTE:   in  this  case,  the  value  of  the  descriptor  E  for   this 
event  is  undefined. 

Normally,  the  event  or  events  to  be  added  by  any  of  the 
three  forms  of  the  ADD  instruction  are  inserted  at  the  end 
of  the  table.  The  user  may,  however,  indicate  where  in  the 
table  the  event  is  to  be  added  by  specifying  before  or  after 
which  row  (indicated  by  the  row  number)  he  wishes  it  to  be 
added.  This  specification  is  in  the  form  of  a  simple  VL1 
condition  (only  one  selector  is  necessary).  For  example,  to 
add  the  event  E1  to  the  beginning  of  table  T,  the 
instruction  would  be: 


ADD  E1  TO  T:[BOH  <  1 ] 

There  are  two  retrieval  instructions,  GET  and  LET. 
They  each  create  a  new  relational  table  from  data  in  one  or 
more  relational  tables.  The  relational  table  created  in  a 
GET  instruction  is  printed  out  at  the  user's  terminal,  while 
the  table  created  by  a  LET  instruction  is  only  stored.  A 
label  must  be  assigned  to  the  table  created  by  a  LET 
instruction;  this  label  becomes  the  name  of  the  relational 
table.  In  a  GET  instruction,  the  label  is  optional;  if  it 
is  given,  then  the  retrieved  table  is  retained  (by  the 
system)  under  the  name  given  as  the  label;  if  it  is  not 
given,  then  the  table  is  destroyed  after  being  printed  out. 
(This  is  the  reason  the  label  is  reguired  for  the  LET,  since 
a  label-less  LET  would  not  serve  any  purpose;  the  LET  is 
used  to  create  a  table,  to  be  used  later,  without  having  it 
printed  out.)  Those  tables  created  by  GET  instructions  which 
are  labeled  and  all  those  created  by  LET  instructions  are 
treated  as  those  relational  tables  created  by  DEPINE  and  ADD 
instructions;  the  exception  to  this  is  that  those  created 
by  retrieval  disappear  at  the  end  of  the  session  unless  the 
user  indicates  he  wishes  a  particular  table  to  be  saved. 
The  SAVE  instruction  is  used  for  this  purpose;  the  user 
types  SAVE  followed  by  the  name  of  the  (retrieved)  table  he 
wishes  to  save.  Thus  if  NEMTAB  had  been  a  label  on  a  GET  or 
LET   instruction,   it  would  be  made  a  permanent  table  in  the 


data  base  by  the  instruction: 

SAVE  HEVTAB 

Following  the  (possibly  optional)  label,  there  is  vhat 
shall  be  called  a  relational  table  condition,  vhich  is 
composed  of  two  parts:  a  relational  table  expression  and  a 
condition  on  that  expression.  The  table  expression 
specifies  which  descriptor  or  descriptor  from  vhich  table  or 
tables  are  to  be  used  in  the  retrieval.  If  the  descriptors 
are  from  more  than  one  relational  table,  then  the 
descriptors  are  extracted  from  the  join  of  the  tables 
specified  in  the  retrieval.  The  join  of  tvo  relational 
tables  (which  must  share  a  common  descriptor)  is  defined  as 
a  new  relational  table  hawing  as  descriptors  the  union  of 
the  sets  of  descriptors  from  the  two  tables  and  each  of 
whose  events  is  formed  by  concatenating  an  event  from  the 
first  table  with  an  event  from  the  second  table  vhich  has 
the  same  value  for  the  common  descriptor  (if  for  a  given 
value  of  the  common  descriptor  the  first  table  has  B  events 
with  that  value  for  the  common  descriptor  and  the  second 
table  has  N  events  with  that  value  for  the  common 
descriptor,  then  the  joined  table  has  H*H  events  with  that 
value  for  the  common  descriptor).  The  join  of  K  tables  (K  > 
2)  is  defined  as  the  join  of  the  first  table  with  the  result 
of   joining  the  last  K-1  tables.   Specifying  a  subset  of  the 
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descriptors  of  a  relational  table  (the  join  of  two  or  more 
relational  tables)  causes  the  formation  of  the  projection  of 
the  full  table  (loined  table)  by  extracting  only  those 
descriptors  specified.  The  user  may  also  form  an  expression 
using  the  set  theoretic  operators  "♦"  (union)  ,  "*" 
(intersection) ,  and  "-"  (difference) ;  in  these  cases  the 
two  tables  being  operated  on  must  have  the  same  descriptors 
and  in  the  same  order. 

If  no  descriptors  are  specified  (i.e.  the  name  of  a 
relational  table,  or  the  union,  interection,  or  difference 
of  two  relational  tables,  is  given  without  specifying  any  of 
its  descriptors) ,  then  the  full  set  of  descriptors  from  that 
table  is  retrieved.  Alternatively,  instead  of  specifying 
some  descriptor,  a  function  of  that  descriptor  may  be 
specified.  The  available  functions  are:  IIIH  (minimum)  ,  HAX 
(maximum),  AVG  (average),  SOU,  COUNT  (cardinality),  and 
DOMAIN  (the  set  of  all  values — from  any  relational 
table--which  are  in  the  domain  of  that  descriptor).  Rather 
than  retrieving  all  the  values  for  that  descriptor,  the 
specified  function  is  applied  to  that  descriptor,  and  the 
result  of  that  function  is  vhat  is  "retrieved".  The 
following  are  all  valid  relational  table  expressions: 

T  All  of  table  T 

T(A,B)       Descriptors  A  and  B  from  table  T 

(T.C)        Descriptor  C  from  table  T 
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(T.c,TT.X)   Descriptors  C  and  X  from  the  join  of  tables 

T  AMD  TT 
T*0(A,C)     Descriptors  A  and  C  from  the  union  of 

tables  T  and  0 
T*U(B)       Descriptor  B  from  the  intersection  of 

tables  T  and  U 

(SUM  (T.A)  ,  AVG  (T.B)  ) 

The  condition,  vhich  is  optional,  specifies  which 
events  from  the  relational  table  expression  are  to  be 
retrieved  (all  of  them,  if  no  condition  is  specified) •  The 
condition  is  separated  from  the  relational  table  expression 
by  a  colon,  vhich  has  the  meaning  "such  that".  The  form  of 
the  condition  is  taken  from  that  of  a  formula  in  the  VL1 
logic  system[3].  A  condition  is  the  disjunction  of  one  or 
more  terms,  each  of  vhich  is  the  conjunction  of  one  or  more 
selectors.  In  VL1  a  selector  has  three  parts:  the  referee, 
vhich  is  the  name  of  a  descriptor,  a  comparison  operator 
("<",  "<  =  ",  "=",  "NOT  =",  ••>*•«,  or  ">")  ,  and  the  reference, 
vhich  is  a  list,  each  of  vhose  elements  is  either  a  single 
value  or  a  range  (vhich  is  denoted  by  the  lover  bound,  a 
colon,  and  an  upper  bound) .  A  selector  is  said  to  be 
"satisfied"  if  the  value  of  the  descriptor  in  the  referee 
has  the  proper  relationship  (indicated  by  the  comparison 
operator)  to  the  values  in  the  reference  (for  "=",  it  is 
satisfied   if   the   value  of  the  descriptor  is  is  equal  to  a 
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value— or  within  some  range  of  some  range--in  the  reference; 
for  "NOT  =",  it  is  satisfied  if  the  value  of  the  descriptor 
is  not  equal  to  any  of  the  values — and  is  not  within  any 
range  of  values—in  the  reference;  for  the  other  operators, 
the  reference  usually  only  has  one  value,  in  which  case  the 
value  of  the  reference  is  compared  to  that  value) •  Examples 
of  selectors  are: 

[A=*5] 

[B>7] 

[C  NOT=  TOP, BOTTOM] 

[T.E<=7.3] 

In  the  condition  of  the  data  base  sublanguage,  the  form 
of  the  selector  is  somewhat  expanded  from  that  used  in  VL1. 
The  form  used  in  VL1  corresponds  to  the  first  form  of  the 
selector  in  the  sublanguage;  however,  the  sublanguage  has 
two  additonal  forms.  The  first  of  these  allows  a  relational 
table  condition  as  the  referee  and  another  as  the  reference. 
In  this  case  the  comparison  operators  become  set  theoretic 
comparison  operators,  where  the  relational  table  conditions 
are  treated  as  sets  of  events  (which  they  really  are) ,  and 
with  "<",  M<=",  ">=",  and  M>"  denoting  subset  and  superset 
operations.   Examples  are: 

[  (T.  A)  =  (NEWT. A)  ] 
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[  (B)  <»  TT*0  (P):[  P>10]] 

The  first  example  tests  whether  or  not  the  relational  table 
composed  of  column  A  from  the  table  T  has  the  same  values  as 
column  A  from  the  relational  table  NBiT  (i.e.  the  two 
columns,  treated  as  sets,  are  compared  for  set  equality). 
The  second  example  tests  whether  or  not  the  relational  table 
composed  of  column  B  from  relational  table  T  (which  need  not 
be  specified  if  it  is  the  only  table  with  B  as  a  descriptor) 
is  a  subset  of  the  relational  table  which  is  composed  of  all 
values  of  the  descriptor  F  from  tables  TT  and  0  (i.e.  from 
the  union  of  TT  and  0)  which  are  greater  than  10. 

In  the  final  form  of  the  selector,  the  referee  is  a 
single  event  and  the  reference  is  a  relational  table 
condition.  The  comparison  operators  allowed  are  IN  and  NOT 
IN,  and  the  comparison  is  whether  or  not  the  event  specified 
as  the  referee  is  in  (not  in)  the  relational  table  specified 
by  the  relational  table  expression  in  the  reference.  Some 
examples  of  selectors  of  this  form  are: 

[  (3,2,5.2]  IN  0] 

[  (TABLE, ARH)  NOT  IN  T  (C,  D)  :[  T.  A=5  ]  ] 

A  term  is  satisfied  if  and  only  if  each  of  its 
selectors  is  satisfied,  and  a  condition  is  satisfied  if  and 
only  if  at  least  one  of  its  terns  is  satisfied.    For   each 
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event  in  the  relational  table  expression,  the  condition  is 
applied  to  the  values  of  that  event;  if  the  condition  is 
satisfied,  then  that  event  is  retrieved  and  is  included  in 
the  resultant  relational  table. 

There  is  another  type  of   relational  table  condition 
which   is  called  the  image  set.   It  is  the  set  of  all  values 
of  a  descriptor  (this  set  is  really  a  relational  table) 
which   appear   in   events  with   other   given   values   of 
descriptors  in  the  same  relational  table.   Thus 

(A:B=5) 

is  the  set  of  all  A's  such  that  B  is  5.  Another  useful  form 
is  where  the  descriptor  (or  descriptors)  to  the  right  of  the 
colon  is  not  given  specific  values  but  is  a  descriptor  being 
retrieved,  for  example: 


(A:B) 


where  B  is  a  descriptor  being  retrieved,  is  the  set  of   all 
k's   corresponding  to  that  B. 

As  can  be  seen,  the  retrieval  instructions  have  guite 
sophisticated  capabilities.  As  a  result  they  may  sound 
complicated;  however,  most  retrievals  are  simple  and  can  be 
expressed   simply.    Usually  only   the  descriptors  from  one 
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table  are  specified;  usually  the  condition  has  only  one 
term  and  this  term  has  only  one  or  tvo  selectors;  usually 
the  selectors  are  of  the  first  form  and  only  use  the 
comparison  operators  "3"  or  "NOT  ="  with  only  one  value  in 
the  reference.   Thus  a  typical  statement  would  be: 

GET  T  (A,  B)  :[  B=5] 

More  complicated  retrievals  can  frequently  be  simplified  by 
breaking  them  into  several  LET  instructions  followed  by  a 
GET  (this  does  not  violate  the  principle  of 
non-procedurality,  which  will  be  discussed  in  Chapter  3; 
the  user  is  just  specifying  the  order  in  which  the 
retrievals  are  to  be  done,  and  this  order  may  more  closely 
correspond  to  the  order  in  which  he  thinks  of  the  query) ; 
more  sophisticated  users  will  like  the  flexibility  of  the 
condition,  and  with  a  little  experience  will  be  able  to 
specify  any  retrieval  he  wishes  in  a  single  GET.  The  user 
has  the  freedom  to  choose  which  of  these  methods  he  prefers. 
A  more  complicated  instruction  would  be: 

GET  TB:=T-U(A)  :[  B=2,  10][  D  NOT=LEG]  OR  [B<5]  OR 
[C=YES,FIVE] 
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k  GET  instruction  is  usually  used  to  print  out  pact  (or 
all)  of  a  single  relational  table;  the  table  T  would  be 
printed  using  the  instruction: 


GET  T 


A  LET  is  usually  used  to  make  a  copy  of  pact  (oc  all)  of  an 
existing  celational  table  oc  to  stoce  a  tempocacy  cesult  to 
be  used  in  the  next  retrieval  instcuction;  a  copy  of  the 
table  T  could  be  made  using  the  instcuction: 

LET  NEHT:=T 

Both  the  GET  and  LET,  however  may  be  used  to  perform  more 
complicated  retrievals.  More  examples  ace  pcovided  in  the 
next  chaptec. 

Thece  ace  tvo  instcuction  vhich  ace  used  to  altec  the 
existing  data  in  the  data  base.  One  is  the  CHANGE 
instruction,  vhich  is  used  to  modify  given  entries  in 
relational  tables  by  replacing  current  values  by  nev  values; 
the  structure  of  the  data  base  is  not  changed  at  all*  The 
other  modify  instruction  is  the  DELETE,  which  deletes 
current  events  or  descriptors  (or  any  combination  of  events 
and  descriptors)  from  an  existing  relational  table. 
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The  CHANGE  instruction  is  really  a  compound 
instruction.  It  is  delimited  by  a  CHANGS  statement  and  and 
END  statement.  The  CHANGB  statement  specifies  vhat 
subtable,  or  list  of  subtables,  may  be  modified  within  the 
CHANGE  instruction.  Each  subtable  is  specified  by  a 
relational  table  condition.  Although  this  expression  may  be 
as  general  as  that  used  in  a  retrieval  instruction,  only 
those  expressions  which  extract  a  subtable  from  one  existing 
relational  table  make  sense.  Specifying  a  subtable  to  be 
changed  vhich  is  derived  from  more  than  one  relational  table 
is  analogous  to  passing  an  expression  (in  some  programming 
language)  as  a  parameter  to  a  procedure  and  having  the 
procedure  modify  the  formal  parameter  for  the  purpose  of 
modifying  the  actual  parameter:  there  is  no  corresponding 
variable  in  the  calling  routine  to  modify!  The  CHANGE 
statement  in  the  CHANGE  instruction  causes  the  creation 
(retrieval)  of  a  subtable  or  list  of  subtables.  These 
subtables  are  operated  on  (changed) ,  nithin  the  CHANGE 
instruction,  in  the  user's  workspace;  at  the  end  of  the 
CHANGE  instruction,  the  modified  values  are  copied  back  into 
the  relational  table  from  which  it  was  extracted  (if  the 
subtable  had  been  extracted  from  the  join  of  two  or  more 
tables,  there  would  be  no  corresponding  table  to  return  the 
changed  values  to;  the  join  is  just  a  calculated  table 
which  is  derived  from  values  in  the  data  base  but  does  not 
really   exist   as   part   of  the  real  data  base) •   Nithin  the 
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CHANGE  instruction  the  user  may  use  assignment  statements  to 
modify  existing  entries  in  that  subtable  (or  subtables). 
Each  assignment  statement  may  optionally  have  a  condition 
modifying  it,  specifying  for  vhich  events  that  descriptor 
(which  is  being  assigned  to)  is  to  be  modified  (i.e.  an 
entire  column  may  be  modified) •  If  the  condition  specifies 
row  0,  then  the  name  of  the  descriptor  is  modified  in  that 
table.  Within  the  CHANGE  instruction,  in  addition  to  the 
assignment  statement,  the  user  is  allowed  to  use  a  DISPLAY 
statement  and  a  GET  statement,  vhich  is  restricted  form  of 
the  GET  instruction.  The  DISPLAY  statement  is  used  to 
display  the  current  value  of  the  subtable  (or  subtables) 
being  changed.  The  GET  statement  is  restricted  by  not 
allowing  it  to  have  a  label;  its  purpose  is  only  for  that 
of  display  (e.g.  to  display  the  values  in  the  original 
table  from  which  the  changed  subtable  was  extracted)  and  not 
for  the  purpose  of  creating  new  tables.  To  terminate  the 
CHANGE  instruction,  the  user  enters  either  the  keyword  END 
or  the  keyword  ABORT.  END  causes  the  subtable  (or 
subtables)  in  the  user's  workspace  to  be  copied  back  into 
the  original  table  (or  tables) ;  ABORT  prevents  this 
updating  from  being  done.   A  sample  instruction  would  be: 

CHANGE  T  (A,B) :[  B>2. 3  ]  change  only  descriptors  A  and  B, 

and  only  for  those  rows  where 
B  is  greater  than  2.3 

B:=3*1.2  add  1.2  to  B  in  every  row 

A:=S  :  £  A<9  1         change  the  value  of  A  to  5  in  only 
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those    rows    where    A    is    less   than   9 

DISPLAY  now    display    the   table 

GET   T  (A,B) :[  B>2. 3  ]     display   the   original    subtable 

A:=3    :    [ROW=10]  change   the    value   of    descriptor    A 

in   row    10    to    the   new    value   3 

END 

The  DELETE  instruction  is  used  to  extract  and  dispose 
of  a  subtable  from  an  existing  relational  table  (the 
subtable  may  be  the  entire  table) .  The  subtable  to  be 
deleted  is  specified  by  a  relational  table  condition,  but  as 
in  the  CHANGE  instruction,  the  specification  of  only  the 
subtable  from  one  existing  relational  table  makes  any  sense. 
If  an  entire  column  is  specified  (i.e.  a  descriptor  given 
without  a  condition) ,  then  that  entire  column  is  removed 
from  the  table,  and  the  table  now  has  one  descriptor  fewer. 
If  only  some  of  the  events  for  a  given  descriptor  are 
specified,  then  those  entries  in  the  table  are  left 
undefined.  If  all  the  descriptors  for  a  given  event  are 
deleted,  then  the  event  is  removed  from  the  table.  If  a 
relational  table  is  specified  without  specifying  any 
descriptors  or  a  condition  on  the  rows,  then  the  entire 
relational  table  is  disposed  of  (and  its  name  is  freed  and 
may  be  reused  for  any  purpose) .  Thus  the  DELETE  instruction 
can  serve  any  of  four  different  purposes: 

1.  To  destroy  an  entire  relational  table,  for  example: 
DELETE  T 
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2.  To  delete  a  set  of  descriptors  from  a  relational 

table,  for  example: 
DELETE  T(A,C) 

3.  To  delete  a  set  of  events  from  a  relational  table, 

for  example: 
DELETE  T:[RO»=2,10]  OB  [ A=5  ] 
U.  To  erase  certain  entries  in  a  relational  table,  for 
example: 

DELETE  T(B,D):  [B>7][D=ARH] 
All  four  are  specified  using  the  same  basic  form  but   differ 
in  their  specification  of  what  to  delete. 

The  INDUCE  instruction  is  used  to  induce  a  set  of  VL 
decision  rules  for  a  descriptor  based  on  knowledge  which  the 
system  has  stored  in  tables.  This  knowledge  may  be  in  the 
form  of  relational  tables  of  event  sets,  tables  of 
previously  derived  rules  (either  induced  or  fed  into  the 
system),  or  any  combination  of  event  sets  and  rules.  For 
each  relational  table,  the  user  may  specify  which  descriptor 
is  to  be  used  as  the  class  specification  (the  value  of  that 
descriptor  in  each  event  is  the  class  to  which  the  event 
belongs)  or  that  all  events  from  that  table  belong  to  a 
specified  class  (which  does  not  correspond  to  any  descriptor 
in  the  table) .  If  no  classes  are  given  for  any  of  the 
tables,  and  if  the  descriptor  which  is  to  be  induced  is  not 
in  any  of  the  relational  tables,  then  the  rule  which  is 
induced  covers  the   set   of   events   specified   against   its 
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inverse  (this  is  called  UNICLASS  induction  [5]).  If  there 
is  a  mixture  of  event  sets  and  rules,  then  the  rule  formed 
is  by  feedback  learning  [6].  The  user  may  specify  what 
induction  technique  to  use  in  forming  the  rule;  if  none  is 
given,  and  none  of  the  above  cases  applies,  then  the 
standard  AQVAL  method  [1,7]  is  used  by  default.  The  options 
which  may  be  specified  are  SYMMETRIC  [8]  and  AQVAL;  the 
user  may  also  specify  either  of  UNICLASS  or  FEEDBACK,  but 
these  should  not  be  necessary  since  the  system  can  figure 
out  which  of  these  to  use  based  on  which  types  of  tables  are 
specified.  The  user  may  also  specify  values  of  parameters 
to  be  used  in  running  the  induction  program;  the  values  of 
all  other  parameters  are  either  by  default  or  entered  by  the 
user  in  a  proq ram-driven  conversational  mode  (i.e.  the 
program  asks  for  each  value  individually) .  Some  examples  of 
this  instruction  are: 

INDUCE  R1:=C  USING  T 

INDUCE  SYMMETRIC  R2:  =  DISEASE  USING  T (CLASS= 1 )  ,U  (CLASS=2) 

INDUCE  R4:=A  USING  R3  (RU LE)  , T  (CLASS= A) 

The  first  instruction  forms  a  rule  for  describing  descriptor 
C  of  table  T  using  the  default  (AQVAL)  method  and  labels  the 
new  rule  table  "R1".  The  second  instruction  forms  a 
symmetric  rule  for  a  new  descriptor  called  DISEASE  using  the 
table  T  for  examples   of   DISEAS£=1   and   the   table   U   for 
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examples  of  DISEASE=2;  the  resultant  rule  table  is  called 
"F2".  The  third  example  used  the  feedback  learning  method 
to  form  a  new  rule  table  called  "B4"  updating  the  old  rule 
table  R3  by  using  new  facts  from  the  table  T,  which  uses 
descriptor  A  to  specify  the  class  of  each  event. 

The  DEDUCE  instruction  asks  that  the  value  of  an 
unknown  descriptor  be  deduced  given  a  table  of  rules  and 
optionally  the  values  of  known  descriptors.  These  values 
may  either  be  given  explicitly  or  else  may  come  from  a 
defined  event  (defined  using  the  DEFINE  EVENT  instruction). 
If  the  value  of  the  descriptor  cannot  be  deduced  with  the 
given  information,  the  system  indicates  this  and  may  ask  for 
the  reguired  information,  if  it  is  known  to  the  user.  An 
example  of  the  DEDUCE  instruction  is: 

DEDUCE  C  PROM  R  USING  (2,10, STOVE) 

Here  a  previously  derived  rule  R  is  used  to  deduce  the  value 
of  C  using  the  event  " ( 2, 10, STOVE) ";  the  order  of  these 
values  corresponds  to  the  order  of  the  descriptors  used 
originally  in  forming  R. 

There  are  two  more  instructions  which  do  not  make  use 
of  the  data  base  but  are  sometimes  guite  useful;  these  are 
COMMENT  and  HELP.  COMMENT  allows  the  user  to  enter  a 
comment   in  order  to  document  (for  his  own  purposes)  what  he 
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is  trying  to  do.  The  program  ignores  all  text  up  to  the 
symbol  SND.  A  comment  may  also  be  entered  (PL/1  style) 
between  any  2  symbols  by  enclosing  it  within  the  delimiters 
"/*"  and  "*/"• 

HELP  asks  Cor  help;  the  user  may  either  ask  for  an 
English  language  explanation  of  an  instruction  by  giving  the 
instruction  name  or  may  ask  for  the  production  rule  from  the 
grammar  for  the  sublanguage  for  any  nonterminal  in  the 
grammar  (see  Appendix  A  for  a  listing  of  the  grammar) .  Por 
example: 

HELP  GET 

provides  a  description  of  the  GET  instruction,  while 

HELP  <CONDITION> 

provides  the  production  rule  associated  with  the  nonterminal 
<CONDITION>  (which  is  the  nonterminal  which  derives  all  VL 
conditions) . 
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3.   COMPARISON  KITH  OTHER  SUBLANGUAGES  AMD  EXAMPLES 

The  VL  Relational  Data  Sublanguage  is  modelled  after 
the  relational  sublanguage  ALPHA  [4]  and  the  Variable-Valued 
Logic  language  VL1  [3].  VL 1  vas  chosen  as  a  model  for  two 
reasons.  The  first  is  that  the  sublanguage  is  intended  to 
be  a  subset  of  a  full  language  for  communication  with  the 
Inferential  Computer  Consultant.  The  basis  for  the 
consultant  is  variable-valued  logic  and  its  language  VL1, 
Since  VL1  must  be  used  in  other  aspects  of  the  system — rule 
formation  (induction)  and  rule  processing  (deduction) --a  VL1 
based  data  sublanguage  is  the  natural  choice  for  the  sake  of 
consistency.  In  addition  to  this,  VL1  very  conveniently 
expresses  the  conditions  which  must  be  specified  in  data 
base  operations  (other  sublanguages  freguently  call  these 
conditions  "predicates",  since  they  are  taken  from  Boolean 
logic) .  Since  VL1  is  the  variable-valued  logic  extension  of 
Boolean  logic,  much  of  the  VL  sublanguage  is  already  similar 
to  the  data  sublanguages  which  are  based  on  Boolean  logic, 
which  include  ALPHA.  This  similarity  is  most  notable  in 
simple  retrievals,  where  the  full  power  of  the  VL 
sublanguage  is  not  reguired;  however,  for  more  complicated 
retrievals,  the  VL  sublanguage  simplifies  the  specification 
of  what  the  user  wishes  to  retrieve.  There  are  several 
reasons  that  the  VL  sublanguage  is  often  easier  to  use.  One 
is   that   a   VL 1   selector   allows   a   list  of  values  in  the 


25 

reference.  Host  other  sublanguages  only  allow  predicates  in 
which  the  value  of  a  descriptor  (which  ALPHA  calls  a  domain) 
may  be  compared  with  a  single  value;  in  these  other 
languages,  if  all  rows  having  any  of  several  values  for  a 
given  descriptor  are  desired,  then  a  disjunction  of 
predicates  (if  the  sublanguage  even  allows  disjunction)  must 
be  used,  whereas  in  the  VL  sublanguage,  a  single  selector 
may  be  used.  This  more  closely  corresponds  to  the  English 
language,  where  one  would  say  Hx  eguals  1  or  3"  rather  than 
"x  eguals  1  or  x  eguals  3".  This  simplification  is  a 
consequence  of  the  use  of  variable- valued  logic  and  the 
concept  of  a  descriptor  as  a  multi-valued  logical  variable. 

A  second  simplification  arises  from  the  use  of 
relational  table  conditions,  which  allows  a  secondary 
retrieval  to  be  a  subexpression  of  the  primary  retrieval 
(i.e.  in  the  second  and  third  forms  of  the  selector,  which 
allow  a  relational  table  condition  to  be  in  the 
ref eree--only  in  the  second  form — and  the  reference)  •  This 
makes  it  easier  to  specify  complicated  retrievals  in  a 
single  instruction.  The  sublanguages  SBQOBL  [9]  and  SQUARE 
[10]  allow  this  sort  of  thing  since  they  incorporate  the 
idea  of  a  relational  expression,  but  the  sublanguages  QUEL 
[ 11  ]  and  ALPHA  do  not. 
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The  third  and  most  important  simplification  lies  not  in 
the  actual  syntax  of  the  sublanguage  but  in  the 
specification  of  the  use  of  the  sublanguage.  In  all  the 
other  languages,  the  links  between  tables  must  be  explicitly 
specified.  That  is,  if  tables  T1  and  T2  both  have  a  common 
descriptor  A  and  the  user  wishes  to  refer  to  a  descriptor  B1 
in  T1  corresponding  (through  common  values  of  descriptor  A) 
to  a  descriptor  B2  in  T2,  then  the  guery  will  usually  be 
reguired  to  use  the  predicate: 

T1.A=T2.A 

The  VL  sublanguage  does  not  reguire  this  (although  it  may  be 
specified  if  the  user  wishes  to  aid  the  system  in  finding 
this  link) ;  instead  these  links  are  automatically 
determined  by  the  system  (in  fact,  links  longer  than  one 
table  are  also  allowed  to  be  implicit) •  This  simplifies 
many  retrievals  and  also  simplifies  the  sublanguage:  ALPHA 
and  QUEL  had  to  introduce  the  RANGE  statement  and  ALPHA  also 
existential  guantif ication  for  this  purpose  only. 

The  remainder  of  this  chapter  will  compare,  through 
examples,  the  VL  data  sublanguage  with  the  sublanguages 
ALPHA,  SEQUEL,  SQUARE,  and  QUEL.  All  these  languages  are 
based  the  relational  calculus  rather  than  relational 
algebra.  That  is,  one  does  not  specify,  in  a  guery,  how  to 
perform    the   retrieval   (i.e.    what   operations   must   be 
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performed)  but  what  ace  the  characteristics  of  the  data 
which  is  to  he  retrieved  (and  the  system  takes  care  of 
determining  what  operations  must  be  performed).  This 
approach  is  easier  for  non-mathematicaily  oriented  users  of 
the  subianguage  (and  freguently  for  mathematically  oriented 
users) .  The  specification  of  what  to  retrieve  more  closely 
corresponds  to  the  thought  process  vhich  a  user  must  go 
through  when  he  decides  what  he  wants  retrieved.  Thus  these 
"non-procedural"  sublanguages  will  be  the  only  ones 
considered  here. 

The  relational  tables  used  in  the  following  examples 
are  taken  from  Figure  4.1  on  page  64  of  Date[12];  some  of 
the  examples  are  also  taken  from  Chapter  4  of  Date.  These 
tables  could  be  constructed  in  the  VL  sublanguage  using  the 
following  instructions: 


COMMENT  DEFINE  THE  DESCRIPTORS  AND  KEY  OF  THE  SUPPLIER  ET 

END 

DEPINE  S(S#,SNAME,STATOS,CITY)KEY:=S# 

END 

ADD  TO  S 

(S1,SHITH, 20, LONDON) 
(S2, JONES, 10, PARIS) 
(S3, BLAKE, 30, PARIS) 
(S4,CLABK, 20, LONDON) 
(S5, ADAMS, 30, ATHENS) 
END 

COMMENT  DEFINE  THE  RT-S  P  AND  SP  END 

DEFINE  P(P#,PNAHE, COLOR, iEIGHT)  KEY:=Pi 
SP(S#,P#,QTY)  KEY:«Sf,Pf 

END 

COMMENT  NOW  FILL  IN  THE  TABLE  P    END 
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ADD    TO    P 
(P1, NOT, BED, 12) 
(P2,BOLTrGREEN#17) 
(P3,SCREH,BLUB,17) 

(P4, SCREW, RED, 14) 
(P5,CAH,BLUE,12) 
(P6,COG,RED,19) 
END 

COMMENT  ADD  EVENTS  TO  SP  END 

ADD  TO  SP 

(S1,P1,3) 

<S1,P2,2) 

<S1,P3,4) 

<S1,P4,2) 

(S1,P5,1) 

(Sl,P6,1) 

<S2,P1,3) 

(S2,P2,4) 

<S3,P3,4) 
END 

ADD  TO  SP 

(S3,P5,2) 

<S4,P2,2) 

(S4,P4,3) 

(S4,P5,4) 
END 

ADD  (S5,P5,5)  TO  SP; 

These  tables  may  then  be   printed   out   using   the 

following   GET   instructions  (the  following  is  taken  from  an 

actual  run  of  the  program  implementing  the  VL  language): 

GET  S; 

S 


S# 

SNAME 

STATUS      | 

CITY 

S1 

SMITH 

20| 

LONDON 

S2          | 

JONES 

1           10| 

PARIS 

S3 

BLAKE      | 

30| 

PARIS 

3U 

CLARK       | 

20) 

LONDON 

S5 

ADAMS 

30| 

ATHENS 

GET  P; 


PI 

|  PNANE 

|  COLOR 

-I 

HEIGHT     | 

P1 

NUT 

I  BID 

1 

12| 

P2 

BOLT 

|  GBEEH 

1          17| 

P3 

|  SCREW 

|  BLUB       | 

1          17| 

P4 

SCREW 

|  RED 

1         1<H 

P5 

|  CAfl 

BLUE       | 

12| 

P6         | 

COG 

RED 

1          191 

GET  SP; 


SP 
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s# 

I  Pt 

I  QTY 

S1 

I  P1 

3 

S1 

P2 

2 

S1 

I  P3 

4 

S1 

P4 

2 

S1 

I  P5 

1 

S1          | 

P6         | 

1 

S2 

P1         | 

3 

S2          | 

P2 

4 

S3 

P3         | 

4 

S3          | 

P5 

2 

S4          | 

P2 

2 

S4          | 

P4          | 

3 

S4 

P5 

4 

S5          | 

P5 

5 

Once  these  tables  are  created  (whatever  facilities  the 
other  sublanguages  have  for  creating  relational  tables), 
they  can  be  manipulated  as  follows  in  these  examples  (the 
formulation  of  the  queries  in  SEQUEL,  SQUARE,  and  QUEL,  and 
some  of  those  of  ALPHA  are  those  of  the  author,  who 
apologizes  for  any  misrepresentation  of  these  sublanguages) : 
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1.   Goal:   Retrieve  from  S  the  supplier  number  and  status  of 
suppliers  in  London.   Label  the  result  W. 


VL         GET  « :=S(S#, STATUS) :[ CITY=LONDON  ] 
ALPHA      GET  tf  (S. S#, STATUS) :ClTY-» LONDON* 


SEQUEL     H:SELECT  S#, STATUS 
FROM    S 
WHERE   CITY=»LONDOH» 


SQUARE       H<-  S      (•LONDON1) 

S#, STATUS   CITY 


QUEL       RANGE:  S(X) 

RETRIEVE:  W: X.Si, X. STATUS :X.CITY=« LONDON* 


2.   Goal:  Retrieve  all  of  S 


VL         GET  S 
or 
GET  S(S#,SNAME, STATUS, CITY) 


ALPHA      GET  U  (S) 
or 
GET  V  (S.S#,S.SNAME,S. STATUS, S. CITY) 

SEQUEL     SBLECT  S 


SQUARE  S 

Si, SNAHE, STATUS, CITY 


QUEL       RANGE:  S(X) 

RETRIEVE:  M:X.S#, X.SNAMB,X. STATUS, X. CITY 


3.   Roal:  Retrieve  supplier  number  of  all  suppliers  in  Paris 
whose  status  is  greater  than  20 
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VL  GET     (S.Sf)  :[CITIi3PAHISXSTATOS>20] 

ALPHA  GET    W  (S  .  S  »)  :  S  .  CIT  !=■•  PABI  S  •   A    S.STATOS>20 


SEQUEL  SELECT    S# 

PBOH         S 


WHERE      CITY=,PABIS» 
AND  STATUS>20 


SQUARE  S  (»PABIS,,>20) 

SI    CITY, STATUS 


QUEL        RANGE:  S (X) 

BETBIEVE:  1:1. S#:  (CITY«»PABIS«)  A  (STATUS>20) 


4.   Goal:  retrieve  supplier  number  and  status  of  suppliers 
in  Paris,  in  descending  order  of  STATUS 


VL         GET  S  (S#, STATUS)  : [CITY=PABIS  ] 

OBDEB  DOWN  ON  STATUS 


ALPHA      GET  W  (S . S#, S. STATUS)  : S. CITY=« PABIS* 

DOWN  S. STATUS 


SEQUEL  impossible 
SQUARE  impossible 
QUEL      impossible 


5.   Goal:  Retrieve  supplier  numbers  of  suppliers  vho  supply 
part  P2 


VL         GET  SP(S#) :[ SP.Pi=P2] 
ALPHA      GET  W  (Sp. S t)  : SP. P #= ■ P2 • 
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SEQOEL  SELECT  SI 
PROM  SP 
WHERE  PI=»P2» 


SQUARE       SP   (»P2») 
S*   Pi 


QUEL       RANGE:  S (X) 

RETRIEVE:  H:X.S#:X.P#-,P2I 


6.   Goal:  Retrieve  names  of  suppliers  who  supply  part  P2 


VL         GET  (SNAME)  :[PI=P2] 
or 
GET  (S.SNAME) :[SP.Pi*P2] 


ALPHA      RANGE  SP  X 

GET  W(S.SMAME)  :3X(X.S#*S.S#  A  X.Pi*»P2») 

SEQUEL     SELECT  SNAME 
PROM    S 
WHERE   S#  =  SELECT  S# 

PROM    SP 

WHERE   PI=»P2» 


SQUARE  S    0    SP   (,P2») 

SNAME  Si    Si   PI 


QUEL  RANGE:    S(X):SP(Y) 

RETRIEVE:     W:X. SNAME: (X.Si=Y. SI)    A     (Y.Pi=«P2«) 


7.      Goal:    Retrieve   names  of    suppliers   who  supply   red   parts 
VL  GET  (SNAME)  :[COLOR*RED] 


ALPHA  RANGE    P    X 

RANGE    SP    Y 
G2T    V  (S. SHAME)  : 

1  X  3Y(S.Sl=Y.SI  a     Y.PI=X.Pi    A    X.COLOR=,RED») 
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SEQUEL     SELECT  SHAME 
PROM    S 
WHERE  St  *  SELECT  Si 


PROM    SP 

WHERE   P«  ■  SELECT  Pi 

FROM  P 

WHERE  COLOR='BED» 


SQUARE  S    #    SP    0    P      (•RED1) 

SNAME  Si         Si   Pi    Pi  COLOR 


QUEL       RANGE:  P  ( X)  :  SP  (Y)  :  S  (Z) 
RETRIEVE:  W:z.sname: 

(Z.Si=Y.Si)  a  (Y.Pi  =  X.Pi)  a  (X.COLOR=«  RED1) 


8.   Goal:  Retrieve  the  names  of  the  suppliers  who  supply  at 
least  one  part  supplied  by  S2 


VL         GET  (SHAME)  : [ COUNT { (Pi :SHAME) *  (Pi.Si=S2) >0 ] 

COMMENT  (Pi: SNAME)  is  the  set  of  all  Pi  associated 
with  the  SNAME  being  considered  for  the 
retrieval.   (P#:S#=S2)  is  the  set  of  all  Pi  for 
supplier  S2.  ■ *•  denotes  intersection  of 
these  two  sets  (relational  tables) 
END 


or 


GET  (SNAME) :[  (Pi) <=(Pi:Si=S2)  ] 

COMMENT  •<=•  checks  for  set  inclusion  (subset)  END 


ALPHA  RANGE  SP  X 
RANGE  SP  Y 
GET  W(S. SNAME):  3 X  (X . Si=S . Si) 

A  3  Y  (Y.P#=X.Pi  a  Y.Si=»S2«)) 


SEQUEL     SELECT  SHAME 
FROM    S 

WHERE   S«  =  SELECT  Si 
FROM    SP 

WHERE  Pi  =  SELECT  Pi 
FROM  SP 
WHERE   Si*,S2» 
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SQUARE  S    0    SP    0    SP   ('S2') 

SNAME  Si    Si   Pi    Pi   Si 


QUEL       RANGE:  S(X):SP(Y,Z) 

RETRIEVE:  »:X. SNAME:   (X.Si»Y.Si) 

A(i.pi«z.Pi)  *  (z.si«»s2») 


9.   Goal:  Retrieve  all  part  numbers  and  their 
corresponding  cities 


VL  GET  (SP.Pi,S.CITY) 

ALPHA      GET  W  (SP.  Pi, S. CITY)  :  SP. SMS.  Si) 


SEQUEL     SELECT  Pi, CITY 

WHERE   SP.Pi-S.Si 


SQUARE  TEMP  <-X       €     S,SP 

Pi,Si,CITY         S* 
TEMP 

pi, city 


QUEL  RANGE:    S  (X)  :SP(Y) 

RETRIEVE:     «:  I.  Pi,  X.CITY:  X.SMY. Si 


10.      Goal:    Retrieve   names  of   all   suppliers   who   supply 
all    parts 


VL  GET     (SNAHE)  :[  (Pi: SNAHE)*DOHAIN  (Pi)  ] 


ALPHA  RANGE    P    X 

RANGE    SP    T 
GET    W  (S. SHAME):    Vx  3 Y (¥. Si=S . Si   A    Y.Pi=X.Pi) 
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SBQUBL     SELECT  SHANE 
FBOH    S 
WHERE   S#  *  SELECT  St 


FBOH    SP 

WHERE   Pi  ALL  ■  ALL 

SELECT  Pt 
FBOH   SP 


SQUARE     X       C  S: 
SNAHE 
SP  (S   )  ■    SUPPLY 
Pi   Si  Si     Pi 


QUEL       impossible 


11.   Goal:  Retrieve  the  supplier  numbers  of  those  suppliers 
who  supply  at  least  all  those  parts  supplied  by  S2 


▼L        GET  (SP.Si)  :[  (Pi:Si)  >«(Pi:Si=S2)  ] 


ALPHA      RANGE  P  7. 
RANGE  SP  T 
RANGE  SP  Z 

GET  W(SP.Si)  :  VX(  3Y(I.S#»aS2a  A  Y.Pi=X.Pi) 
->  lZ(Z.Si=S.Si  a  Y.PMX.Pi)) 


SEQUEL     SELECT  Si 

FBOH    SP 

WHERE   Pi  ALL  >=  ALL 

SELECT  Pi 
FROH  SP 
WHEBE  SM»S2» 


SQUARE     impossible 
QUEL       impossible 
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The  remaining  examples  demonstrate  the  VL  CHARGE  and 
DELETE  instructions.  SEQOEL  and  QOEL  do  not  have  such 
instructions  and  will  not  be  included  in  the  following: 

12.   Goal:  Change  the  color  of  part  P2  to  yellow 


VL  CHANGE  (COLOR) :( P#=P2 ] 

COLOR :=YELLOH 
END 


or 


CHANGE  P(P#, COLOR) 

COLOR :=YELL0»:[P#*P2] 
END 


ALPHA      HOLD  W (P. P#, P. COLOR) : P.PMP2 
V. COLOR=YELLOW 
UPDATE  W 


SQUARE     ->  P  (»P2»  ,»YELLOW«) 

P#;COLOR 


13.   Goal:  Increase  by  1  the  guantity  of  each  part  supplied 
by  S1 


VL  CHANGE  (QTY) :[ S#=S1  ] 

QTY:=QTY*1 
END 


ALPHA      HOLD  M(QTY) :SP.S#=,S1» 
H.QTY=B.QTY*1 
UPDATE  W 


SQUARE     ->  SP         (»S1»  ,1) 

S#;QTY+ 
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14.   Goal:  Multiply  by  2  the  quantity  of  each  part  supplied 
by  5  1  and  make  sure  this  number  does  not  exceed  5;  if  it 
does,  set  it  equal  to  5 


VL  CHANGE     (QTY) :[ SP. S#=S1 ] 

QTY:*QTY*2 
QTY:=5    :    [QTY>5] 
END 


ALPHA      HOLD  8(SP.QTY) :SP.S#=«S1« 

W.QTY=W.QTY*2 
UPDATE  « 
HOLD  W(SP.QTY)  :  SP.SM'SVa  QTY>5 

W.QTY=5 
END 


SQUARE     ->  SP         (»S1»,2) 

S#;QTY* 
->  SP  («S1»,>5,5) 

S#,QTY;QTY 


15.   Goal:  Delete  from  S  all  suppliers  in  London 
VL         DELETE  S: [ CITY=LO NDON  ] 


ALPHA      HOLD  U <S) :CITY=» LONDON • 
UPDATE  B 


SQUARE     ^  S     ('LONDON1) 
CITY 


16.   Goal:  Destroy  the  entire  relational  table  P 

VL         DELETE  P 


ALPHA      HOLD  I (P) 
DELETE  i 


SQUARE     t  P 
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17.   Goal:  Remove  the  descriptor  COLOR  from  P 
VL         DELETE  (P. COLOR) 
ALPHA     impossible 
SQUARE    impossible 
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4.   IMPLEMENTATION  OP  THE  SUBLANGUAGE 


The  program  implementing  the  VL  data  sublanguage  is 
written  in  PASCAL  using  the  PASBEL  compiler  for  the  PDP-10 
computer  at  the  University  of  Illinois.  The  program  is  a 
set  of  externally  compiled  procedures  which  are  called  from 
the  control  program  (also  written  in  PASCAL)  of  the  computer 
consultant.  There  are  two  major  phases  to  the  program:  a 
parser,  which  is  implemented  by  an  external  procedure  called 
PARSE,  and  an  execution  package,  implemented  by  an  external 
procedure  called  EXEC.  The  parser  converts  each  instruction 
entered  by  the  user  into  an  internal  form  which  is  passed  to 
the  execution  package  to  actually  execute  the  user's 
instruction.  The  separation  into  two  phases  serves  two 
purposes.  First,  it  follows  the  philosophy  of  structured 
and  modular  programming  by  keeping  different  functions  in 
separate  procedures  (the  functions  of  syntactic  analysis, 
which  is  performed  by  PARSE,  and  the  true  processing  of  the 
instruction,  which  is  performed  by  EXEC)  and  keeps  the  user 
interface  localized.  The  second  purpose  is  concerned  with 
errors  which  may  occur  in  the  user's  input;  only 
syntactically  correct  instructions  are  passed  to  the 
execution  package.  This  is  guite  important  in  the 
interactive  environment  of  the  computer  consultant  (as 
opposed  to  the  environment  of  a  batch  or  timesharing 
computer   program   which   may  be  rerun  after  corrections  are 
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made).  If  each  instruction  were  executed  up  to  the  point  of 
a  syntax  error—or  if  the  execution  supervisor  attempted  to 
ignore  these  errors  or  tried  to  execute  vhat  it  thought  the 
user  meant--the  data  base  might  end  up  unalterably 
scrambled.  For  example,  if  the  execution  supervisor  vere  in 
the  middle  of  adding  or  deleting  a  relational  table  or  an 
event  but  did  not  finish  because  of  errors  in  the  user's 
input,  the  internal  data  structures  used  to  represent  the 
data  base  might  end  up  so  jumbled  that  parts  or  all  of  the 
data  base  would  be  lost.  The  system  cannot  ensure  that  the 
user  is  alvays  specifying  exactly  that  which  he  intends,  but 
it  can  attempt  to  protect  the  user  as  much  as  possible  from 
errors.  By  parsing  an  entire  instruction  before  beginning 
any  execution  of  it,  the  system  attempts  to  do  this.  A 
desirable  side  effect  of  the  two  phase  process  is  that  it 
would  be  possible  for  another  module  within  the  computer 
consultant  to  access  the  data  base  through  the  sublanguage 
by  generating  the  appropriate  internal  text  and  passing  it 
to  EXEC.  No  such  attempts  have  been  made,  but  the 
possibility  is  being  considered. 

The  parser  is  hard  coded  (as  opposed  to  being  table 
driven)  and  uses  the  recursive  descent  parsing  technigue. 
These  choices  were  made  in  the  interest  of  ease  of 
implementation  and  debugging  as  well  as  ease  of 
understanding  by  anyone  reading  the  program  (table  driven 
programs   and  hard  coded  ones  using  other  parsing  techniques 
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are  usually  more  difficult  to  follow) .  For  each  instruction 
(DEFINE,  SAVE,  ADD,  GET,  LET,  CHANGE,  DELETE,  INDUCE, 
DBDOCE,  and  HELP),  the  source  teit  is  read  in  and  the 
relevant  information  is  encoded  into  a  format  suitable  for 
processing  by  the  execution  supervisor.  The  data  into  vhich 
it  is  encoded  is  referred  to  as  the  internal  text  and  is  in 
the  form  of  an  integer  array  called  PT  (for  parse  table) • 
The  first  three  words  of  this  array  serve  the  same  function 
for  all  instructions:  the  first  word  contains  the  length  of 
the  array  as  it  was  declared;  the  second  contains  the  code 
for  the  instruction  type;  the  third  contains  the  length  of 
the  actual  portion  of  the  array  used  by  the  instruction. 
After  this,  each  instruction  has  its  own  coding,  although 
consistency  is  maintained  whenever  common  structures  are 
encountered.  Por  example,  the  condition  part  of  the  GET, 
LET,  CHANGE,  and  DELETE  instructions  are  translated 
identically.  All  expressions  (arithmetic,  relational  table, 
and  VL)  translated  into  a  postfix  string  (contiguous 
elements  of  PT)  .  Real  numbers  and  strings  are  stored  as 
indices  into  auxiliary  arrays  of  the  appropriate  types  (a 
real  array  called  BEALN  and  an  array  of  strings — of  length 
20--called  SUITABLE).  The  complete  meaning  of  the  entries 
in  PT  is  given  in  Appendix  B. 

During  a  session,  the  entire  data  base  is  stored  in 
core.  Although  this  places  a  restriction  on  the  size  of  the 
data   base,   it   was   felt   that   the   size   and   number   of 
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relational  tables  one  would  want  to  use  for  the  computer 
consultant  would  be  within  the  limits  that  can  be  provided. 
The  advantage  to  storing  everything  in  core  is  that  the 
entire  data  base  can  be  quickly  and  easily  accessed* 
Dynamic  storage  is  used  whenever  possible  so  that  only  as 
much  storage  must  be  allocated  as  is  needed.  As  a  result  of 
this  approach  there  are  few  built-in  limits. 

Each  relational  table  has  a  header  node,  and  these 
nodes  are  storage  as  a  linked  list.  The  header  node  is 
implemented  as  a  PASCAL  record  containing  the  following 
fields: 

RTNAME — contains  the  name  of  the  relational  table.  It 
is  a  pointer  to  a  programmer  defined  data  type  called 
STRING,  which  is  a  record  variant:  PASCAL  allows  a  field  of 
a  record  to  be  one  of  several  variants.  When  the  record  is 
allocated,  the  programmer  specifies  which  one  of  these 
variants  he  wishes  the  field  to  be.  By  choosing  the 
variants  to  be  strings  of  various  lengths  (a  string  in 
PASCAL  is  an  array  of  single  characters,  and  the  length  of 
the  array  is  the  length  of  the  string);  thus  only  exactly 
the  number  of  characters  which  are  needed  is  allocated. 

N^XTRT'-a  pointer  to  the  header  node  for  the  next  table 
in  the  linked  list. 
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ROH0PTR--a  pointer  to  the  0-th  row  (the  row  of 
descriptors)  in  the  relational  table. 

ROWLASTPTR--a  pointer  to  the  last  row  of  the  relational 
table.   This  allows  rows  to  be  added  to  the  end  easily. 

RTN0H--the  relational  table  number,  which  is  assigned 
by  the  program  and  is  used  for  internal  references  to  the 
table  (rather  than  having  to  use  the  name) • 

N0«KEYS--the  number  of  descriptors  in  the  key  of  the 
table;  the  descriptors  in  the  key  are  the  first  NOHKEYS 
descriptors  in  the  table. 

STATUS — indicates  what  type  of  table  it  is  (used  for 
the  purpose  of  saving  or  deleting  it).  The  following  values 
mean  the  table  has  the  given  status: 

-1: temporary  (created  by  a  LET   or   a   labeled   GET). 
The   table   will   remain  only  until  the  end  of  the 
session,  unless  a  SAVE  instruction  is  used. 
0: temporary  (created  by  an  unlabeled   GET   or   as   a 
result   of  a  subexpression) .   It  will  be  destroyed 
as  soon  as  the  program  is  through  with  it. 
1: permanent  table  (created  by  a  DEFINE  or  saved  by  a 
SAVE)  .    It  will  be  saved  on  disk  when  the  session 
is  over  and  read  back  in  for  the  next  session. 
2:event  (created  by  a  DEFINE  EVENT   instruction   and 
saved  only  until  the  end  of  the  session) . 
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A  row  in  a  relational  table  is  also  a  record;  the 
first  field  is  NEXTROW,  which  is  a  pointer  to  the  next  row 
in  the  same  table.  The  next  field  is  a  record  variant, 
whose  variants  are  integer  arrays  of  various  lengths.  The 
length  allocated  is  the  number  of  descriptors.  The  tag 
field,  which  indicates  which  variant  was  chosen,  contains 
the  length  of  that  array.  This  is  why  the  header  node  does 
not  need  to  store  the  number  of  descriptors  in  the 
table—each  row  contains  that  information. 

The  0-th  row  contains  the  descriptor  numbers  for  the 
descriptors  in  the  table.  There  is  a  table  of  descriptors 
which  is  managed  by  another  program  within  the  computer 
consultant.  This  table  associates  with  each  descriptor  a 
number  which  it  uses  for  internal  reference  to  that 
descriptor  (in  much  the  same  manner  as  relational  table 
numbers  are  used)  .  The  table  of  descriptors  program  can 
return  a  descriptor  number  given  a  descriptor  name  and  visa 
versa.  The  NFXTROB  pointer  points  to  the  first  row  of  the 
table,  which  is  the  first  event  in  the  table.  The  integers 
in  that  row  (and  all  subseguent  rows)  are  value  numbers, 
which  are  also  associated  with  values  (integers,  reals,  or 
names)  by  the  table  of  descriptors  program.  The  table  of 
descriptors  keeps  a  list  of  all  the  values  within  the  domain 
of  each  descriptor  and  the  program  can  associate  value 
numbers  with  values  and  their  corresponding  descriptor 
names.   Thus  only  integers  are  needed  in  the  storage   for   a 
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relational   table   to   represent   the   descriptors  and  their 

values. 

The  variables  BTHEAD  and  RTTAIL  point  to  the  first  and 
last  header  nodes,  respectively,  in  the  linked  list  of 
relational  tables.  These  two  variables  are  all  that  are 
needed  (usually  only  RTHEAD)  to  access  all  of  the  relational 
tables;  thus  it  is  quite  easy  to  pass  the  tables  as 
parameters  to  external  procedures  (this  is  sometimes  a 
problem  in  PASCAL  since  there  are  no  external  variables) • 

PARSE  contains  or  uses  the  following  procedures,  whose 
descriptions  are  given  belov: 

VLSCAN--obtains  the  next  token  from  the  user's  input 
and  classifies  it.  The  parameter  SYBBCLASS  is  given  the 
value  of  the  class  of  the  symbol;  the  possible  classes  are 
RES  (reserved  word),  RTN  (relational  table  name),  EVN  (event 
name) ,  DES  (descriptor  name) ,  TXT  (either  a  character  string 
or  an  alphanumeric  name  which  is  neither  of  RES,  RTN,  EVM, 
or  DES),  INT  (integer),  RLN  (real  number),  DBL  (2  character 
delimiter,  one  of  ":  =  ",  or  "<=»,  ">=••),  DLB  (1  character 
delimiter) ,  or  IGN  (a  comment,  which  is  to  be  ignored) .  The 
token  is  returned  in  NXTSYMB  as  a  string.  For  character 
strings  and  alphanumeric  names,  it  is  also  returned  as  a 
longer  string  (20  characters)  in  the  array  LONGSYHB;  if  it 
is  an  integer,  its  value  is  returned  in  NXTIHT;  if  it  is  a 
real,  its  value  is  returned  in  NXTREAL. 
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VLERR1  —  prints  out  an  error  message  when  a  syntax  error 
is  found,  indicating  what  token  was  erroneously  input  and 
what  token  was  expected.  It  also  sets  MOERRORS  to  FALSE  to 
inhibit  execution  of  the  instruction. 

VLERR2 — prints  out  a  longer  error  message  than  VLERR1 
and  also  sets  NOERRORS  to  FALSE. 

VERIFY  — verifies  that  the  current  symbol  matches  the 
parameter  SYHB,  which  is  what  is  expected.  If  they  do  not 
match,  then  VLERR1  is  called. 

DESCINRT — determines  if  the  descriptor  number  MD  is  in 
the  relational  table  number  NRT. 

SCAN — calls  VLSCAM  with  the  appropriate  external 
parameters.  This  is  done  so  that  each  call  to  VLSCAN  does 
not  have  to  pass  all  the  parameters  (this  would  produce  much 
more  object  code) • 

ADDSYHB — adds  a   string   (the   current   symbol)    to 

SYMTABLE. 

LOOKRELOP — determines  if  the  current  symbol  is  a 
relational  operator. 

GETDESO-obtains  the  descriptor  number  and  relational 
table  number  of  the  current  (and  following)  symbol. 
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VALUE—parses  a  value,  vhich  may  be  an  arithmetic 
expression  or  a  name.  It  fills  in  PT  with  the  postfix 
translation  of  the  expression. 

CONSTANT — (vithin  VALUE)  parses  a  single  constant, 
vhich  is  an  integer,  a  real  number,  or  a  name. 

APACTOR-- (within  VALUE)  parses  an  arithmetic  factor. 

ATPRM-- (vithin  VALUE)  parses  an  arithmetic  term. 

RTCOND--parses  a  relational  table  condition,  vhich 
consists  of  a  relational  table  expression  and  (optionally)  a 

VL  condition. 

CONDITION--parses  a  VL  condition  and  fills  in  PT  with 
the  postfix  translation  of  the  value. 

SELECTOR—  (vithin  CONDITION)  parses  a  selector. 

VLTERM--  (vithin  CONDITION)  parses  a  VL  terra. 

VLDEPINE — parses  a  DEPINE  instruction 

DEPRT- (vithin  VLDEPINE)  parses  the  definition  of  one 
relational  table. 

VLADD--parses  an  ADD  instruction 

ADDVAL--  (within  VLADD)  parses  a  list  of  event  in  an  ADD 
instruction. 
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ADDTO — (within  VLADD)  parses  the  relational  table  name 
to  which  the  event  or  events  are  to  be  added  and  the  row 
condition  (if  any),  which  specifies  where  in  the  table  the 
event  or  events  are  to  be  added. 

VLCHANGE — parses  a  CHANGE  instruction. 

CHANGE-- (within  VLCHANGE)  parses  a  single  CHANGE 
statement. 

VLDELETE — parses  a  DELETE  instruction. 

VLHELP — parses  a  HELP  instruction. 

VLCOHMENT--parses  a  comment. 

VLSAVE — parses  a  SAVE  instruction. 

STHTYPE--deterraines  the  type  of  instruction  and  sets 
the  code  in  the  variable  NXTKEYHD. 

PF0LL--an  external  procedure  from  the  table  of 
descriptors  program  which  fills  in  (in  the  table  of 
descriptors)  the  name  of  a  new  descriptor. 

TODNEW — an  external  procedure  from  the  table  of 
descriptors  program  which  allocates  storage  for  a  new 
descriptor. 
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EXEC  contains  or  uses  the  following  procedures,  whose 
descriptions  are  given  below: 

NFWSTR-~a  function  which,  given  a  string  stored   as  an 

array   of  twenty  characters  returns  a  pointer  to  a  record  of 

type  STRING  with  only  the  number  of  characters  allocated  as 
are  needed  (trailing  blanks  are  trimmed  off). 

FIMDRT — a  function  which,  given  a  relational  table 
number,  returns  a  pointer  to  the  header  node  for  that  table. 

FINDROW--a  function  which,  given  a  relational  table 
number  and  the  number  of  a  row  in  that  table,  returns  a 
pointer  to  the  row. 

PRTVAL — prints  out  a  record  of  type  TVALUE  (which  has 
as  record  variants  the  types  INTEGER,  REAL  and  STRING) . 

ALLOO-allocates  a  new  row  of  length  LENGTH  for  a 
relational  table.  This  procedure  is  used  rather  than 
directly  calling  the  built-in  procedure  NEB,  which  ALLOC 
calls,  since  NEW  reguires  as  parameter  a  constant  to 
indicate  which  variant  to  allocate,  while  ALLOC  allows  this 
parameter  to  be  a  variable  (or  an  expression) . 

SALLOC--allocates  a  STRING  of  length  LENGTH;  this 
procedure  is  needed  for  the  same  reason  ALLOC  is. 
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NEWBTN — allocates  and  fills  in  a  header  node  for  a  nev 
relational  table. 

CONDITION — evaluates  a  VL  condition  and  determines 
whether  or  not  it  is  satisfied  for  a  given  event. 

MATCH--determines  whether  or  not  the  key  in  a  nev  event 
to  be  added  to  some  relational  table  matches  the  key  of  an 
event  already  in  the  table. 

DEFINE — executes  a  DEFINE  instruction.  For  DEFINE  HT, 
it  allocates  and  fills  in  a  nev  header  node.  Also,  the  0-th 
row  is  allocated  and  filled  in  vith  the  appropriate 
descriptor  numbers.  For  a  DEFINE  EVENT  instruction,  an 
event  is  treated  as  a  relational  table  vith  only  one  row. 
In  addition  to  allocating  and  filling  in  the  header  node  and 
the  0-th  row,  the  first  row,  which  is  the  event,  is 
allocated  and  filled  in. 

ADD--executes  an  ADD  instruction.  It  adds  a  nev  row 
(or  rows)  to  a  relational  table  (after  insuring  that  there 
is  no  other  row  in  that  table  vith  the  same  key  value)  vith 
the  appropriate  value  numbers.  If  a  defined  event  is  to  be 
added,  the  the  values  for  the  event  are  first  rearranged  (if 
necessary)  to  match  the  order  of  the  descriptors  in  the 
relational  table. 
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DEL£TE--executes  a  DELETE  instruction.  If  an  entire 
relational  table  is  to  be  deleted,  then  the  header  node  is 
removed  from  the  linked  list  of  such  nodes;  this 
effectively  frees  the  relational  table  name  to  be  used  for 
any  purpose.  If  a  set  of  descriptors  are  to  be  deleted, 
then  the  entire  table  must  be  recopied  saving  only  those 
descriptors  not  deleted.  The  descriptors  are  not  removed 
from  the  table  of  descriptors  since  they  may  be  in  use  as 
descriptors  of  other  relational  tables.  If  a  set  of  events 
is  to  be  deleted,  then  they  are  just  removed  from  the  table. 
If  the  intersection  of  a  set  of  descriptors  or  events  are  to 
be  deleted  (erased) ,  then  the  appropriate  entries  are  set  to 
be  undefined. 

GETLPT--erecutes  a  GET  or  a  LET  instruction. 

GETSUBSET — (within  GETLET)  forms  a  new  relational  table 
with  the  subset  of  the  original  table  (or  join  of  two  or 
more  tables)  which  satisfies  the  condition  and  the  subset  of 
descriptors  which  were  specified. 

DISPLAY-- (within  GETLET)  prints  out  the  resultant  table 
from  a  GET  instruction) . 

GETHAP — (within  GETLET)  sets  up  a  map  of  the  descriptor 
numbers   from   the  original  table  (or  join  of  tables)  to  the 

retrieved  table. 
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SAVE — executes  a  save  instruction  by  setting  the  status 
of  the  relational  table  to  "permanent"  so  that  i t  is  saved 
on  disk  at  the  end  of  the  session. 

PCARD — an  external  function  from  the  table  of 
descriptors  program  which  returns  a  value  number  given  a 
value  and  a  pointer  to  the  corresponding  descriptor. 

NFIND-an  external  function  from  the  table  of 
descriptors  program  vhich  returns  a  pointer  to  a  descriptor 
given  the  descriptor  number. 

VALPDP — an  external  procedure  from  the  table  of 
descriptors  program  vhich  returns  a  descriptor  value  given  a 
pointer  to  the  descriptor  and  the  value  number. 

The  sequence  of  actions  vhich  the  program  performs  when 
an  instruction  is  entered  by  the  user  is  as  follows:  First, 
PARSE  is  called  to  parse  the  instruction*  Within  PARSE, 
first  STHTYPE  is  called  to  determine  what  type  of 
instruction  it  is.  This  sets  the  instruction  type  variable, 
nxtkeywd,  and  the  appropriate  parsing  procedure  is  called. 
If  there  are  no  errors  in  the  instruction  (if  PABSE  returns 
with  NOERRORS  having  the  value  TRUE),  and  if  the  instruction 
is  one  which  requires  execution  (COMMENT  and  EXIT  do  not) , 
then  2XEC  is  called  with  the  internal  text.   EXEC  first 
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determines  what  type  of  instruction  it  was  (from  PT[2J)  and 
calls  the  appropriate  procedure  to  execute  the  instruction. 
The  instruction  is  then  executed. 
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APPENDIX  A 


GRAMMAR  POR  VL  RELATIONAL  DATA  SUBLANGUAGE 


The  following  is  a  complete  syntax  specification  for 
the  VL  sublanguage.  Anything  enclosed  in  [  and  }  is 
optional;   anything  enclosed  in  (  and  •••}  may  be  repeated  0 

or  more  times. 


SESSION 
VLI 

CREATE 
DEFINF_INS 
DEF  LIST 


:=  {<VLI>;  ...)  EXIT 

:=  <CREATE>  I  <RETRIEVE>  |  <MODIFY> 
|  SAVE  <RTNAHE>  |  COMMENT  (any  text)  END 
|  <INDDCE>  |  <DEDUCE>  |  <HELP> 

:=  <DEFINE_INS>  |  <ADD_INS> 

:=  DEFINE  <DEF_LIST>  END 

:=  {RT}  <RTNAME>  (<DBSC>  {,<DBSC>...}) 
(KEY:=<DESC>  [,<DESC>...}} 
{<RTNAME>(<DESC>{,<DESC>...}) 
{KEY:=<DESC>[,<DESC>... )}...} 
|  EVENT  <EVENTNAME>:* 

(<DESC>:*<VALUE>{,<DESO:=<VAL0E>. ..}) 

C<eventnjIme>:* 


(<DESC>:=<VAL0E>(,<DESO:=<VALUE>..  .})...) 


ADD    INS 


ROW_ 

.COND 

LT 

GT 

ROW_ 

VAL 

HODIPY 

:=    ADD    TO   <RTNAME>f:<ROH_COND>) 
(<VALUE> (,<VALOE>. ..} ) 
{(<VALPE>[,<VALOE>... })...} 
END 
|     ADD    <EVENTNAMB>   TO    <BTNAME> {:<BON_COND>} 
|    ADD     (<VALUE>(,<VALUE>...))     TO    <RTNAME> 
(:<ROW_COND>) 

:=    [ROW    <GT>    <ROW_VAL>] 
|    ("ROW    <LT>    <ROW_VAL>] 

=    < 

=    > 

=    <VALUE>    |     LAST 

=*    CHANGE     (RT)     {<LABEL>:=*}     <RTCOND> 

{,  {<LABEL>:=}     <RTCOND>...} 
<CHANGE_STHT>(<CHANGE_STMT>... } 
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END_CHANGB 
LABEL 
CHANGE  STHT 


BTCOND 

CSYN 

CONDITION 

¥L_TEHH 

SELECTOB 

RELOP 

VALUES 

?ALOE 

Bote:  "?H 
ISET 

AEXPB 
ATERH 

AFACTOB 
BT 

TEXPB 

Note:  "♦" 
TTERH 

Note:  "*" 


<EMD  CHANGE> 
|  DELETE  (RT)  <HTCOND>  (,<BTCOND>  ...) 

■  END  |  ABOBI 
=  <RTNAHB> 

■  <DBSO:*<YALUE>(:<CONDITION>} 
|  <DESO:  =  <NEHNAME>:[  ROB  =  0  ] 
|  GET  <BTCOND>  {<OBDEB>} 
|  DISPLAY  {<BTNABB>} 

:=  <BT>  (<CSYH>  <CONDITIOM>}  |  ISET 

=  :  |  WHERE 

»    <YL_TEBH>     [OB    <VL_TEBH>. . .} 

■  <SBLECTOB>     {<SELECTOR>...} 

=    [<DESO'<BELOP>    <VALUBS>(,VALUBS>...}  ] 

|    [<BT_COND>    <BELOP>    <RT_COND>] 

|    [<VALUE>(,<VALUE>...}    "(NOT)     IN    <RT_COND>  ] 

:=    <LT>    |    <LT>=    |    =    |    NOT-    |     <GT>=     |    <GT> 

:=    <VALUE>    {:<VALUB>} 

:=  <AEXPB>  |  <ISET>  |  <NAHE>  |  ? 

means  the  value  is  unknown;  it  is  left  undefined 

::=  (<DESC>  <CSYB>  <DBSC>  (=<VALOB>) 

(,<DBSC>  {=<?ALUE>} .-•}) 

::«  {<AEXPR>  ♦  }  <ATEBM>  |  <AEXPR>  -  <ATERH> 

::=  f<ATERH>  *}  <AFACTOR> 
J  <ATERM>  /  <AFACTOR> 

::*    <COHSTANT>    |      (<AEXPB>)     |     -    <APACTOB> 

::=  <TEXPR>  ((<DESC>  {,<DESC>...}) 

|   (<DESC>  {,<DESC>...}) 

::*  f<TEXPB>  ♦  )  <TTEBM>  |  <TBXPB>  -  <TTEBH> 
is  set  union;  "-"  is  set  difference 

::=  f<TTERH>  *)  <TFACTOB> 
is  set  intersection 
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TFACTOR 
DESC 

FUNCTION 

FUNCNAHE 
RETRIEVE 

ORDER 

INDUCE 
METHOD 
KNOWLEDGE 

KTYPE 
CLASS 

CLASS_NUMBER 
PARMS 

DEDUCE 

EVENT 
HELP 

INSTRUCTION 


:«   <BTNAME>    |     (<BT_COMD>) 

=    <DESCNAME>    |     <RTN AME> . <DESCNAHE> 

|    <DESCNAME>   OF    <BTNAHE> 

|    <RTNAHE>. .<BTHAHE>,<DESCNAME>    |     <FUNCTION> 

!■   <FUNCNAME>    ( (<DESC> {, <DESC>, •}) } 

=    ATG    |    HIM    |    MAX    J    SDH    |    COUNT    |     DOHAII 

:■    GET    {HT}     (<LABEL>2*)     <BT_COND>    {<OBDEB>} 
|    LET    {BT}    <LABEL>:=   <BT_COND>    {<OBDEB>} 

-    OBDEB    UP    ON    <DESC>    {#<DESC>...} 
|    ORDER    DOHN    ON    <DESC>    (,<DESC>...} 

INDUCE    {<METHOD>}     <LABEL>:=<DESCBIPTOB> 

USING    <KNOWLEDGE>    {<PARMS>} 
AQVAL    |    SYHHETBIC    |    UNICLASS    |    FEEDBACK 

<RTNAHE>(<KTYPE>)      {,<BTNAME> (<KTYPE>) ..•} 
<RTNAHE>     {,<RTNAME>...} 


RULE    |    CLASS=<CLASS> 

<CLASS_NUMBEB>    |     <DESCRIPTOB> 

<INTEGEB> 

PARAMETERS (<PABH>:*<VALUE> 

{, <PARM>:=<VALUE>. . .}) 

!■    DEDUCE   <DESCRIPTOB>    FBOH    <BTNAME> 
(WITH   <EVENT>} 

=    <EVENTNAME>    |     (<VALUE>  (,<VALUE>.  ..}  ) 

=    HELP    <LT>    <NONTERMINAL>    <GT> 
I     HELP    <INSTRUCTION> 


DEFINE    |     ADD    |    GET    |    LET    |    CHANGE    |    DELETE 
EXIT     |    COMMENT     |     INDUCE    |     DEDUCE    |     HELP 
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APPENDIX  B 
Heaning  of  the  Elements  of  the  Array  PT 


INSTROCTION 

ARRAY  ELEMENT   HEANING 


DEFINE 


1  Length  of  PT 

2  1  (DEFINE) 

3  Length  of  PT  used 

4  Number  of  BT's  or  Erents  defined 

For  each  RT  defined 

x  Length  of  PT  used  for  this  this  RT 

x  +  1  1  (Indicates  DEFINE  RT) 

x  +  2  Index  in  SYBTABLE  of  the  rtname 

x  +  3  Number  of  descriptors  (nd) 

x  +  4  Number  of  key  descriptors  (nk) 

x+5  First  descriptor  number 

x+6  Second  descriptor  number 


x+4+nd         Last  descriptor  number 
x+4+nd+1       First  key  descriptor  number 
x+4+nd+2       Second  key  descriptor  number 


x+4+nd+nk  Last  key  descriptor  number 

For  each  Event  defined 

x  Length  of  PT  used  for  this  Event 

x+1  2  (indicates  DEFINE  EVENT) 

x+2  Index  in  Symtable  of  event  name 

x+3  Number  of  descriptors  (nd) 

x  +  4  First  descriptor  number 

x+5  First  value 

x+6  First  value  type 

x+7  Second  descriptor  number 

x+8  Second  value 

x+9  Second  value  type 


x+3nd+1        Last  descriptor  number 
x+3nd+2         Last  value 
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ADD 


CHANGS 


x+3nd+3        Last  value  type 


1  Length  of  PT 

2  2  (ADD) 

3  Length  of  PT  used 

4  Type  of  Add 

1:  ADD  TO 

2:  ADD  event 

3:  ADD  (value,  value, ...) 

5  BT  number  to  be  added  to 

6  Row  condition  operator 

0 :  none 
1:  < 
2:  > 

7  Row  number  (or  -1  if  none  given) 

Por  types  1  and  3 

8  Number  of  events  to  be  added  (ne) 

9  Number  of  descriptors  (nd) 

10  Pirst  value  type 

0:  unknown  ("?"  entered) 

1:  integer 

2:  string  or  name 

3:  real 

11  Second  value  type 


9+nd  Last  value  type  code 

9*nd«-1         Pirst  value  for  first  event 
9*nd*2         Second  value  for  first  event 


9+nd+ne        Last  value  for  first  event 
9*nd*ne*1       Pirst  value  for  second  event 


9*nd*nd*ne     Last  value  for  last  event 

Por  type  2 

8  Event  number 


1  Length  of  PT 

2  3  (CHANGE) 

3  Length  of  PT  used 
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DELETE 


HELP 


U  Number  of  tables  to  be  changed 

5  First  label 

First  relational  table  condition 
Second  label 

Second  relational  table  condition 


Last  label 
Last  relational  table  condition 

For  each  CHANGE  STATEMENT 

x  type  of  statement 

1  Assignment 

2  DISPLAY 

3  GET 
U  END 

5  ABORT 


1  Length  of  PT 

2  4  (DELETE) 

3  Length  of  PT  used 
relational  table  condition 


1  LENGTH  OF  PT 

2  5  (HELP) 

3  Type  of  help 

1:  command 
2:  <nonterminal> 
I*  Index  in  SYMTABLE  of 

command  or  nonterminal 


GET  and  LET 


1  LENGTH  OF  PT 

2  6  (GET)  or  7 (LET) 

3  Length  of  PT  used 

4  Index  in  SYMTABLE  for  label 
relational  table  condition 

x  Order  operator 

0:  none 

1 :  up 

2:  Down 
x*1  Number  of  descriptors  to  order 

on  (nd) 
x+2  First  descriptor  number 

x*3  Second  descriptor  number 


62 


SAVE 


x*1+nd         Last  descriptor  number 


1  Length  of  PT 

2  8  (SAVE) 

3  Length  of  PT  used 

4  Relational  table  number 


The  following  is  the  format  for  a  relational 
table  condition 

1  Number  of  relational  tables  in 

expression  (nr) 

2  Number  of  first  relational  table 

3  Number  of  descriptors  used  in  first 

table  (nd) 

4  First  descriptor  number 

5  Second  descriptor  number 


3+nd  Last  descriptor  number 

3+nd+1         Number  of  descriptors  used  in  2nd 

table 


Length  of  PT  used  for  condition 
Condition  in  Polish  postfix 
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